home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7984 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: anvil.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Zombies & Daemons
  5. Date: 28 Feb 1996 11:19:15 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4h29rjINNamh@anvil.ugrad.cs.ubc.ca>
  8. References: <3134348F.7526@citenet.net>
  9. NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
  10.  
  11. In article <3134348F.7526@citenet.net>,
  12. Oliver Lavery  <oliver@citenet.net> wrote:
  13. >I've just finished writting a daemon to handle generating web 
  14. >pages from an Oracle database. When it executes, the parent forks a 
  15. >number of children, all of which are bound to a network port. Each child 
  16. >services requests in order etc. etc. works more or less like an apache 
  17. >httpd...
  18. >
  19. >    The problem is this: when one of the children dies for whatever 
  20. >reason (usually a f*cked OCI call which makes the daemons session 
  21. >unstable), the parent's sigcld handler forks a new child to keep a 
  22. >consistent number of processes running. For some reason, however, the 
  23. >dead child process lingers around as a zombie process ... how do I avoid 
  24. >this?
  25.  
  26. Your program is failing to observe the UNIX semantics for starting and
  27. finishing concurrent tasks. A forked process must be waited for with a special
  28. system call named wait(), or waitpid(). The man page for wait should tell you
  29. all the possibilities.
  30.  
  31. The simiplest call, wait(), simply ``reaps'' the next available zombie. If no
  32. child has exited, it will block until a child does exit. You can call it from
  33. the signal handler. When a child that exited (or crashed or was terminated) is
  34. waited for, it ceases to be a zombie and is cleared from the system. The parent
  35. is able, through the wait() family of system calls, to obtain the exit status
  36. of the child, or if the child failed to exit properly, information such as
  37. whether the child made a core dump, etc.
  38.  
  39. Get a book called ``Advanced Programming in the UNIX Environment''. Go to
  40. comp.unix.programmer. Read the FAQ. This is not really a comp.lang.c question.
  41. A competent C master who doesn't know anything about UNIX (if such a person
  42. exists) would not be able to answer.
  43.  
  44. Also, learn about reliable signal handling with sigaction(), if you aren't
  45. using it already.
  46.  
  47. >    Also, does SunOS support copy on write memory pages? And do 
  48. >zombie processes still use system resources?
  49.  
  50. Yes. At the very _least_ they occupy a process table entry. Whether they occupy
  51. virtual space is a matter of implementation, but you know that since a zombie
  52. has a process ID, it is occupying at least a kernel process control block.
  53.  
  54. I do believe that SunOS supports this. It should not concern you greatly unless
  55. you are doing an exec() in the child process just after the fork(). The
  56. system's manual page on fork() and vfork() should tell you whether vfork() is
  57. recommended for launching a child that immediately execs(). In modern UNIX
  58. systems, vfork() is obsoleted, since fork() is done using copy-on-write.
  59. -- 
  60.  
  61.